Add support for IP mediums, v2 #346
Conversation
|
Very nice. Did a superficial inspection and it looks much better, with less code duplication. I was also bothered by having to duplicate the ethernet to tun interface. Gonna test everything tomorrow, thanks! |
|
I've pushed a new set of commits removing @whitequark let me know what you think! |
Dirbaio
force-pushed
the
ip-interface-alt
branch
from
00f7252
to
fb2f580
Compare
|
Rebased to latest master. @whitequark I was wondering if you've had time to look at it. Is this new approach something you'd be interested in merging? any feedback? |
|
I'll take a look soon. |
|
I've been using this fork and it works :) |
|
I'm going to review this over the weekend. |
|
Has anyone tested this fork with a high transfer rate application? I made a C++ interface for it based on this pull request: https://github.com/lucaszanella/smoltcp_cpp_interface and then I used it to send IP packets through an OpenVPN connection (that I modified to accept packets from memory rather than from tun/tap) I modified the socket of an RTSP client to be a socket that sends things through this smol VPN tunnel that I created, but after some seconds (sometimes 1 second, sometimes 5 seconds), the client receives a packet that it shouldn't receive and stops working. I'm debugging this problem for more than a week and couldn't find anything wrong on my C++ interface. I captured the RTSP/RTP packets of the camera using wireshark, and compared wth packets dumped from the smol stack. I wrote a python script that verifies packet per packet if the packet produced by smol stack matches with the packet produced by the camera. After some packets it finds one that was delivered by the stack that was not delivered by the camera. It's not a malformed packet, is just a different one. If anyone has any idea on what might be happening I'd be happy to know! |
|
Hi, nothing is wrong with these changes, I found my error. This pull request works perfectly, I already did a libcurl downloader and an RTSP client that uses this PR and it's working great! |
|
Hi @whitequark , is there any plan for merging this PR? |
Sure, I'll review it when I have time. |
Functions that only deal with IP packets take/return IpPacket's. IpPacket's are wrapped into EthernetPacket's as late as possible. This will later allow generalizing Interface to handle both Ethernet and pure-IP mediums.
Dirbaio
force-pushed
the
ip-interface-alt
branch
from
fb2f580
to
fe25529
Compare
|
Rebased to latest master |
- Add `medium` in `DeviceCapabilities`. - Rename EthernetInterface to Interface. - Add support to Interface for both Ethernet and IP mediums. The medium to use is detected from `device.capabilities().medium`. - Ethernet-only features are gated behind the "ethernet" feature, as before. - IP features are always enabled for now.
Dirbaio
force-pushed
the
ip-interface-alt
branch
from
fe25529
to
eeab246
Compare
|
Pushed new version:
|
|
I'm lost, where is the |
|
PR moved to #401 which includes your TunInterface work |
This is a new attempt at implementing #334, addressing the shortcomings found in the first version (#336) detailed in #336 (comment).
So far I'm quite pleased by how it turned out. The only big structural change in
Interfaceis checking forDevice.medium()in send and receive paths and adjusting the behavior accordingly. The rest of the changes are mostly boilerplate and updating the tests.This includes the Linux tun work by @LucasZanella from Dirbaio#1, squashed and updated for the v2 changes.
Things that need fixing:
mediuminto account, always interprets as Ethernet)Possible future work:
medium_ipfeature DONEethernetfeature tomedium_ethernetfor consistency? DONEInterfacewith dynamic dispatch to the device, check how much improvement in binary size is there vs static dispatch.